System and method for providing a persistent snapshot of a running system in a distributed data grid

ABSTRACT

A system and method can support persistence in a distributed data grid, such as providing a persistent snapshot of a running system. The system allows one or more cache services to run on a plurality of cluster members in the distributed data grid. Furthermore, the system can collect a catalogue of state information associated with said one or more cache services from the plurality of cluster members in the distributed data grid, and create a snapshot for said one or more cache services running on the distributed data grid.

CLAIM OF PRIORITY

This application claims priority on U.S. Provisional Patent ApplicationNo. 61/915,912, entitled “SYSTEM AND METHOD FOR SUPPORTING PERSISTENCEIN A DISTRIBUTED DATA GRID” filed Dec. 13, 2013, which application isherein incorporated by reference.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to the following patent application(s), eachof which is hereby incorporated by reference in its entirety:

U.S. patent application titled “SYSTEM AND METHOD FOR SUPPORTING SERVICELEVEL QUORUM IN A DATA GRID CLUSTER”, application Ser. No. 13/352,203,filed on Jan. 17, 2012 (Attorney Docket No. ORACL-05131US2);

U.S. patent application titled “SYSTEM AND METHOD FOR SUPPORTINGPERSISTENCE PARTITION DISCOVERY IN A DISTRIBUTED DATA GRID”, applicationSer. No. ______, filed ______, 2014 (Attorney Docket No.ORACL-05462US0); and

U.S. patent application titled “SYSTEM AND METHOD FOR SUPPORTINGPERSISTENT STORE VERSIONING AND INTEGRITY IN A DISTRIBUTED DATA GRID”,application Ser. No. ______, filed ______, 2014 (Attorney Docket No.ORACL-05463US1).

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF INVENTION

The present invention is generally related to computer systems, and isparticularly related to supporting persistence in a distributed datagrid.

BACKGROUND

Modern computing systems, particularly those employed by largerorganizations and enterprises, continue to increase in size andcomplexity. Particularly, in areas such as Internet applications, thereis an expectation that millions of users should be able tosimultaneously access that application, which effectively leads to anexponential increase in the amount of content generated and consumed byusers, and transactions involving that content. Such activity alsoresults in a corresponding increase in the number of transaction callsto databases and metadata stores, which have a limited capacity toaccommodate that demand. This is the general area that embodiments ofthe invention are intended to address.

SUMMARY

Described herein are systems and methods that can support persistence ina distributed data grid, such as providing a persistent snapshot of arunning system. The system allows one or more cache services to run on aplurality of cluster members in the distributed data grid. Furthermore,the system can collect a catalogue of state information associated withsaid one or more cache services from the plurality of cluster members inthe distributed data grid, and create a snapshot for said one or morecache services running on the distributed data grid.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is an illustration of a data grid cluster in accordance withvarious embodiments of the invention.

FIG. 2 shows an illustration of supporting persistence in a distributeddata grid, in accordance with an embodiment of the invention.

FIG. 3 shows an illustration of using a shared storage to supportpersistence in a distributed data grid, in accordance with an embodimentof the invention.

FIG. 4 shows an illustration of using distributed local disks to supportpersistence in a distributed data grid, in accordance with an embodimentof the invention.

FIG. 5 shows an illustration of supporting distributed persistent storerecovery in a distributed data grid, in accordance with an embodiment ofthe invention.

FIG. 6 shows an illustration of coordinating persistent store recoveryin a distributed data grid, in accordance with an embodiment of theinvention.

FIG. 7 shows an illustration of supporting consistent partition recoveryin a distributed data grid, in accordance with an embodiment of theinvention.

FIG. 8 illustrates an exemplary flow chart for supporting distributedpersistent store recovery in a distributed data grid in accordance withan embodiment of the invention.

FIG. 9 shows an illustration of supporting persistent store versioningin a distributed data grid, in accordance with an embodiment of theinvention.

FIG. 10 shows an illustration of supporting persistent store integrityin a distributed data grid, in accordance with an embodiment of theinvention.

FIG. 11 shows an illustration of restoring the persisted partitions in adistributed data grid, in accordance with an embodiment of theinvention.

FIG. 12 illustrates an exemplary flow chart for supporting persistentstore versioning and integrity and in a distributed data grid, inaccordance with an embodiment of the invention.

FIG. 13 shows an illustration of providing a persistent snapshot of arunning system in a distributed data grid, in accordance with anembodiment of the invention.

FIG. 14 illustrates an exemplary flow chart for providing a persistentsnapshot of a running system in a distributed data grid in accordancewith an embodiment of the invention.

DETAILED DESCRIPTION

Described herein are systems and methods that can support persistence ina distributed data grid.

Distributed Data Grid

In accordance with an embodiment, as referred to herein a “data gridcluster”, or “data grid”, is a system comprising a plurality of computerservers which work together to manage information and relatedoperations, such as computations, within a distributed or clusteredenvironment. The data grid cluster can be used to manage applicationobjects and data that are shared across the servers. Preferably, a datagrid cluster should have low response time, high throughput, predictablescalability, continuous availability and information reliability. As aresult of these capabilities, data grid clusters are well suited for usein computational intensive, stateful middle-tier applications. Someexamples of data grid clusters, e.g., the Oracle Coherence data gridcluster, can store the information in-memory to achieve higherperformance, and can employ redundancy in keeping copies of thatinformation synchronized across multiple servers, thus ensuringresiliency of the system and the availability of the data in the eventof server failure. For example, Coherence provides replicated anddistributed (partitioned) data management and caching services on top ofa reliable, highly scalable peer-to-peer clustering protocol.

An in-memory data grid can provide the data storage and managementcapabilities by distributing data over a number of servers workingtogether. The data grid can be middleware that runs in the same tier asan application server or within an application server. It can providemanagement and processing of data and can also push the processing towhere the data is located in the grid. In addition, the in-memory datagrid can eliminate single points of failure by automatically andtransparently failing over and redistributing its clustered datamanagement services when a server becomes inoperative or is disconnectedfrom the network. When a new server is added, or when a failed server isrestarted, it can automatically join the cluster and services can befailed back over to it, transparently redistributing the cluster load.The data grid can also include network-level fault tolerance featuresand transparent soft re-start capability.

In accordance with an embodiment, the functionality of a data gridcluster is based on using different cluster services. The clusterservices can include root cluster services, partitioned cache services,and proxy services. Within the data grid cluster, each cluster node canparticipate in a number of cluster services, both in terms of providingand consuming the cluster services. Each cluster service has a servicename that uniquely identifies the service within the data grid cluster,and a service type, which defines what the cluster service can do. Otherthan the root cluster service running on each cluster node in the datagrid cluster, there may be multiple named instances of each servicetype. The services can be either configured by the user, or provided bythe data grid cluster as a default set of services.

FIG. 1 is an illustration of a data grid cluster in accordance withvarious embodiments of the invention. As shown in FIG. 1, a data gridcluster 100, e.g. an Oracle Coherence data grid, includes a plurality ofcluster members (or server nodes) such as cluster nodes 101-106, havingvarious cluster services 111-116 running thereon. Additionally, a cacheconfiguration file 110 can be used to configure the data grid cluster100.

Persistent Storage of Cache Contents

In accordance with an embodiment of the invention, the distributed datagrid can provide recoverable persistent storage for different types ofcache content and can prevent data loss after the distributed data gridis shut down.

FIG. 2 shows an illustration of supporting persistence in a distributeddata grid, in accordance with an embodiment of the invention. As shownin FIG. 2, a distributed data grid 200 can include various types ofcache content 211-213 in an in-memory data store 202. Furthermore, thedistributed data grid 200 can use a persistence layer 201 to persist thecache content 211-213 in a persistent storage 203.

The persistence layer 201 allows the persistent storage 203 to usedifferent physical topologies. For example, the persistence layer 201can store the cache content in a central location, such as a storagearea network (SAN) 221, where all members in the distributed data grid200 can share the same visibility. Alternatively, the persistence layer201 can store the cache content into different local disks 222, wheremembers of the distributed data grid 200 may have only local visibility.

Furthermore, the persistence layer 201 can be agnostic to the choice ofthe physical topology (e.g. a SAN 221 or distributed local disks 222).For example, the distributed data grid 200 can take advantage ofmultiple SANs or multiple SAN mount points. Also, the distributed datagrid 200 can take advantage of a physical topology that includesmultiple SANs that are not shared by the plurality of members.Alternatively, the physical topology may include multiple SANs exportingstorage locations, or may include hybrid deployments of local disks andSANs.

Additionally, the persistence layer 201 can support partition-wideatomicity of persisted data/metadata, and can provide transactionguarantee after a restart of the distributed data grid 200. Also, thepersistence layer 201 can minimize performance impact and reducerecovery time needed to restart the distributed data grid 200.

FIG. 3 shows an illustration of using a shared storage to supportpersistence in a distributed data grid, in accordance with an embodimentof the invention. As shown in FIG. 3, a distributed data grid 300, whichincludes a plurality of members (e.g. the members 301-305 on themachines A-C 311-313), can support various cache services 320.

Furthermore, the distributed data grid 300 can use a shared persistentstorage, such as a storage area network (SAN) 310, to store the cachecontent for the cache services 320 in a central location. As shown inFIG. 3, the different members 301-305 on the machines A-C 311-313 canshare the same visibility, and can all have access to the persistedpartitions 322 in the SAN 310.

Thus, the system can recover the persisted cache content and preventdata loss, when the distributed data grid 300 is restarted after ashutdown.

FIG. 4 shows an illustration of using distributed local disks to supportpersistence in a distributed data grid, in accordance with an embodimentof the invention. As shown in FIG. 4, a distributed data grid 400, whichincludes a plurality of members (e.g. the members 401-405 on themachines A-C 411-413), can support various cache services 420.

Furthermore, the distributed data grid 400 can store the cache contentfor the cache services 420 into the local disks on different machines.For example, the members 401-402 can store the related cache contentinto the local disk A 431 on machine A 411 (e.g. the persistedpartitions 421). Also, the members 403-404 can store the related cachecontent into the local disk B 432 on the machine B 412 (e.g. thepersisted partitions 422), and the machine C 413 can store the relatedcache content into the local disk C 433 on the machine C 413 (e.g. thepersisted partitions 423).

Thus, the distributed data grid 400 can support the automatic recoveryof various types of cache content in a distributed fashion, and preventdata loss during the restart of the distributed data grid 400.

Distributed Persistent Store Recovery

In accordance with an embodiment of the invention, the distributed datagrid can support persistent store recovery in a distributed fashion.

FIG. 5 shows an illustration of supporting distributed persistent storerecovery in a distributed data grid, in accordance with an embodiment ofthe invention. As shown in FIG. 5, a distributed data grid 500 caninclude a plurality of members, e.g. members 501-505, and can persistthe cache content using the distributed local disks, e.g. local disksA-C 511-513.

Furthermore, each member in the distributed data grid 500 may only havevisibility to the partitions persisted in the local disk. For example,the member 501 and the member 502 may only be aware of the persistedpartitions 521 in the local disk A 511, while the member 503 and themember 504 may only be aware of the persisted partitions 522 in thelocal disk B 512 and the member 505 may only be aware of the persistedpartitions 523 in the local disk C 513.

In accordance with an embodiment of the invention, the distributed datagrid 500 can use an internal protocol to discover the persistedpartitions 521-523 on different local disks A-C 511-513. For example,the discovery protocol supports the persistent store recovery duringboth the cluster cold-start/restart scenario and the multiple-nodefailure scenario (e.g. with a loss of a primary owner of a partitionand/or one or more backup owners of the partition).

As shown in FIG. 5, the distributed data grid 500 can use a coordinatormember 510 to coordinate the recovery of various persisted partitions521-523 in the distributed data grid 500. The coordinator member 510 cansend a distributed query to other members 501-505 in the distributeddata grid 500 in order to obtain a complete list of persisted partitions521-523.

In accordance with an embodiment of the invention, the coordinatormember 510 can use a pluggable partition assignment strategy component520 to determine the partition recovery assignment 540. For example, thesystem can go down the list of the partitions to examine which membercan see a version of the partition. Then, the system can determine whichmember should be used to recover which partition based on a synchronizedpartition ownership view 530.

Furthermore, the system can minimize the performance impact caused byadding persistence support to the distributed data grid 500. Forexample, the system can use an asynchronous messaging process in thedistributed data grid 500 for implementing the write operation to apersistent store. Also, the system allows the performing of multipleinput/output (I/O) operations concurrently.

Additionally, the coordinator member 510 can avoid using only one or afew members in the distributed data grid 500 for performing therecovery, which may be prone to create performance bottleneck.

Also, the system can use a recovery quorum to ensure that all persistedpartitions are visible prior to the recovery in order to prevent dataloss due to recovery.

Additional descriptions of various embodiments of supporting servicelevel quorum in a distributed data grid 500 are provided in U.S. patentapplication titled “SYSTEM AND METHOD FOR SUPPORTING SERVICE LEVELQUORUM IN A DATA GRID CLUSTER”, application Ser. No. 13/352,203, filedon Jan. 17, 2012 (Attorney Docket No. ORACL-05131US2), which applicationis herein incorporated by reference.

Thus, the distributed data grid 500 can automatically carry out arecovery of persisted cache contents in a distributed fashion during arestart of the distributed data grid 500.

FIG. 6 shows an illustration of coordinating persistent store recoveryin a distributed data grid, in accordance with an embodiment of theinvention. As shown in FIG. 6, a coordinator member 610 in a distributeddata grid 600 can coordinate the recovery of the persisted partitionsfrom the distributed local disks. For example, the coordinator member610 can direct a member 620 to recover persisted partitions from a localdisk 630.

At step 601, the coordinator 610 can instruct the member 620 (and allother members in the distributed data grid 600 concurrently) to preparefor restoring persisted partitions. Then, at step 602, the member 620(possibly along with each other member in the distributed data grid 600)can provide a local partition ownership back to the coordinator member610.

At step 603, the coordinator member 610 can synchronize a view of theoverall partition ownership, after obtaining the partition ownershipinformation from the different members in the distributed data grid 600.

Furthermore, at step 604, the coordinator 610 can instruct the member620 to prepare for recovering the persisted partitions based on the viewof the overall partition ownership. At step 605, the member 620 cancheck for the persisted partitions in the local disk 630. Then, at step606, the member 620 can report the persisted partitions (e.g. thepersisted partition IDs) in the local disk 630 to the coordinator member610.

At step 607, after obtaining information about the persisted partitionsfrom the different members in the distributed data grid 600, thecoordinator member 610 can make decision on how to configure a recoveryprocess, such as determining a recovery assignment.

Then, at step 608, the coordinator 610 can provide the partitionrecovery assignment (e.g. the recover partition IDs) to each member inthe distributed data grid 600. Finally, at step 609, the differentmembers in the distributed data grid 600 (including the member 620) cancarry out the recovery of the persisted partitions based on the receivedpartition recovery assignment.

FIG. 7 shows an illustration of supporting consistent partition recoveryin a distributed data grid, in accordance with an embodiment of theinvention. As shown in FIG. 7, a distributed data grid 700 can include aplurality of members, e.g. members 701-705, each of which may only havevisibility to the partitions persisted in the local disk.

Furthermore, a coordinator member 710 can coordinate the recovery ofvarious persisted partitions 721-723 from the distributed local disksA-C 711-713. Also, the coordinator member 710 can use a pluggablepartition assignment strategy component 720 to determine which membershould be used to recover which partition.

In accordance with an embodiment of the invention, when a machine in thedistributed data grid 700 is lost, the system can promote in-memorybackups to in-memory primaries. As part of this process, the system cancreate a new persisted partition on disk and can also create one or morein-memory backups on other members from the data in memory.

Additionally, when in-memory data loss occurs due to two or more(depending on the backup count) member processes dying simultaneously,the system can recover a new in-memory primary from the persistedversion on disk, when there is a member having visibility to the disk.

As shown in FIG. 7, when a machine that is associated with the localdisk A 711 is lost, the persisted partitions 721 may become unavailable.In such a case, the distributed data grid 700 can rebalance itself. Forexample, the distributed data grid 700 can promote a back-up partitionwhich is persisted in either the local disk B 712 or the local disk C713 as the primary partition.

In accordance with an embodiment of the invention, the distributed datagrid 700 can ensure that the system always restores the most recentvalid partition. For example, the persisted partitions 722 in the localdisk B 712 may contain a newer version of the partition, since thepersisted partitions 721 in the local disk A 711 may not be updatedcorrectly or an older version of the partition exists due to the deathof the prior owner of the partition.

In accordance with an embodiment of the invention, the distributed datagrid 700 can use a recovery quorum for supporting the discovery and/orthe recovery of the persisted partitions 721-723. By using the recoveryquorum, the recovery from persistence can be gated or protected. Thus,the distributed data grid 700 can ensure that no data is lost, even whenthe number of members that are lost exceeds the in-memory redundancytarget.

Also, the distributed data grid 700 can ensure that all persistedpartitions are visible prior to recovery. For example, the recoveryquorum can be configured such that it guarantees visibility to all ofthe possible storage locations (such as local disks and/or SANs withinthe cluster). Additionally, the distributed data grid 700 can recoverorphaned partitions from the persistent store and assign them as emptypartitions

Furthermore, the distributed data grid 700 can establish differentrecovery policies based on the recovery quorum. For example, thedistributed data grid 700 can establish SAN/shared-storage policies thatfocus on capacity. Also, the distributed data grid 700 can establishdistributed/shared-nothing storage policies that ensure all storagelocations are reachable. Also, the distributed data grid 700 canestablish various policies based on the configured membership size andthe host-list.

In accordance with an embodiment of the invention, the system allowsvarious members 701-705 in the distributed data grid 700 to be shut down(and/or restarted) in an orderly fashion, and allows for a gracefulsuspend/resume of an service or the entire cluster. Additionally, thesystem can prevent partition transfers and persistent store movements,during the shutdown of the distributed data grid. For example, aquiesced service/cluster may not join new members, may not restorepartitions from backup, may not recover orphaned partitions frompersistent store, may not assign empty orphaned partitions, and may notperform partition distribution.

FIG. 8 illustrates an exemplary flow chart for supporting distributedpersistent store recovery in a distributed data grid in accordance withan embodiment of the invention. As shown in FIG. 8, at step 801, thesystem allowing a plurality of members in the distributed data grid topersist a plurality of partitions associated with one or more cacheservices in a persistent storage. Then, at step 802, a coordinator cansynchronize a view of partition ownership among the plurality of membersin the distributed data grid. Furthermore, at step 803, the distributeddata grid can form a distributed consensus on which partition can berecovered from which member in the distributed data grid.

Persistent Store Versioning and Integrity

FIG. 9 shows an illustration of supporting persistent store versioningin a distributed data grid, in accordance with an embodiment of theinvention. As shown in FIG. 9, a distributed data grid 900 can usevarious partitions (e.g. a partition 901) in an in-memory data store 920to support different cache services.

Furthermore, the distributed data grid 900 can use a persistent store(e.g. a persisted partition 911) to persist the partition 901 in thedistributed local disks 910.

The system can provide a unique identifier (ID), or a unique versionnumber 906, for each persisted partition in the distributed local disks910. As shown in FIG. 9, a member 902 in the distributed data grid 900can generate a globally unique identifier (GUID) 921 for the persistentpartition 911. The GUID 921 can contain various types of informationusing a special naming format.

For example, the GUID 921 can include at least a partition number (or apartition ID 903) and a partition version number 911 associated with thepartition 901. Additionally, the GUID 921 can contain a member ID 904,which indicates that the member 902 generates the GUID 921.

Additionally, the GUID 921 can include other information, such as a timestamp 905 that indicates the time when the partition 901 is firstpersisted. The time stamp 905 is a stamp of logical time (e.g. a stampof a vector clock per partition), instead of a global wall clock. Thus,the system can guarantee that the GUID stamps move monotonically forwardin the face of any kind of failure or transfer scenario.

In accordance with an embodiment of the invention, the distributed datagrid 900 can maintain the version number 910 for each persistedpartition in a monotonically increasing order. Thus, the system canaccount for the data mutation at any member or ownership changes in thedistributed data grid 900.

FIG. 10 shows an illustration of supporting persistent store integrityin a distributed data grid, in accordance with an embodiment of theinvention. As shown in FIG. 10, a persistent store 1001 in a distributeddata grid 1000 can contain cache content from different caches A-C1011-1013, each of which is associated with a cache ID 1021-1123.

Furthermore, the system can apply a seal operation 1002 on thepersistent store 1001. The seal operation 1002 can ensure that thepersistent store 1001 is fully initialized and is eligible to berecovered.

Additionally, the system can apply a validation operation 1003 on thepersistent store 1001. The validation operation 1003 can check whetherthe persistent store 1001 has been sealed. For example, the system maydecide that the cache content in the persistent store 1001 is not validif the persistent store 1001 is not sealed.

Thus, the system can ensure that the distributed data grid 1000 alwaysrestores a valid persisted partition and avoids recovering a partialcopy that may be caused by cascading cluster failures.

FIG. 11 shows an illustration of restoring the persisted partitions in adistributed data grid, in accordance with an embodiment of theinvention. As shown in FIG. 11, a distributed data grid 1100 can storevarious persisted partitions 1111-1113 in distributed local disks 1110.

Each persisted partition 1111-1113 stored in the distributed local disks1110 can be associated with a globally unique identifier (GUID), e.g.GUID 1141-1143. The GUIDs 1141-1143 can contain different types ofinformation that includes at least a partition number (i.e. apartition-id) and a version number.

In accordance with an embodiment of the invention, the members 1101-1102in the distributed data grid 1100 may have different visibility to thepersisted partitions 1011-1013 in the distributed local disks 1110. Thesystem can configure the GUIDs 1141-1143 to contain information on whichmember may have visibility to a particular persisted partition1111-1113.

Additionally, as a result of a cascading failure in the distributedlocal disks 1110, multiple versions of the same persisted partitions1011-1013 may present on the different members 1101-1102 of thedistributed data grid 1100. In order to disambiguate these differentversions, each of the members 1101-1102 in the distributed data grid1100 can report the GUIDs 1141-1143 (which can include the partitionnumbers and other information) for each of the persisted partitions thatare found. In accordance with an embodiment of the invention, onlymembers reporting the presence of the most recent GUID for a partitioncan be considered for recovery.

As shown in FIG. 11, each member 1101-1102 in the distributed data grid1100 can collect a list of available GUIDs 1121-1122 from thedistributed local disks 1110 based on local visibility. Then, eachmember 1101-1102 can provide (or register) the list of available GUIDs1121-1122 to a resolver 1103 in the distributed data grid 1100, and theresolver 1103 can determine the newest GUIDs 1130 for differentpartitions based on the partition number and version number informationencoded in the GUIDs 1141-1143.

Furthermore, due to the distributed nature of the system, thedistributed local disks 1110 may contain multiple different versions ofthe same partition. In other words, the resolver 1103 may receivemultiple GUIDs that contain the same partition number and differentversion numbers.

In such a case, the resolver 1103 can obtain the version number fromeach GUID associated with the same partition, and determine which GUIDhas the most recent version number. Also, the distributed data grid 1100can ensure that the persisted partition with the most recent versionnumber is valid based on performing the seal operation and validationoperation.

Additionally, the resolver 1103 can determine which member 1101-1102 inthe distributed data grid 1100 is responsible for recovering aparticular persisted partition 1111-1113, based on the member IDinformation encoded in the GUIDs 1141-1143.

Then, the resolver 1103 can provide the partition recovery assignment,which may include a list of the newest GUIDs 1131-1132, to eachdifferent member 1101-1102. Accordingly, the members 1101-1102 can carryout the actual operation that restores the persisted partitions1111-1113.

Thus, the system can ensure that the distributed data grid 1100 alwaysrestores the newest valid version of any persisted partition, and canavoid recovering a partial copy that may be caused by cascading clusterfailures.

FIG. 12 illustrates an exemplary flow chart for supporting persistentstore versioning and integrity and in a distributed data grid, inaccordance with an embodiment of the invention. As shown in FIG. 12, atstep 1201, the system can receive a plurality of identifiers (e.g. theGUIDs) from one or more members of the distributed data grid, whereineach said identifier is associated with a persisted partition in apersistent storage for the distributed data grid. Then, at step 1202,the system can select an identifier for each partition, wherein eachselected identifier is associated with a most recent valid version of apartition. Furthermore, at step 1203, the system can determine a memberin the distributed data grid that is responsible for recovering saidpartition from a persisted partition associated with the selectedidentifier.

Persistent Snapshot of a Running System

FIG. 13 shows an illustration of providing a persistent snapshot of arunning system in a distributed data grid, in accordance with anembodiment of the invention. As shown in FIG. 13, a distributed datagrid 1300 can support various cache services 1320 using an in-memorydata store 1302.

Furthermore, the system allows a user to use a management tool 1310 totake a snapshot 1301 of the running system on the in-memory data store1302 that supports the cache services 1320 on-demand, at any particulartime. For example, the snapshot 1301 can be used to make a backup of therunning system overnight.

In accordance with an embodiment of the invention, the system cansuspend the cache services 1320, prior to taking the snapshot 1301.Thus, the system can provide a consistent point in time for taking thesnapshot 1301. Then, the cache service 1320 can be resumed after thesnapshot 1301 is taken.

Additionally, the snapshot 1301 can provide a consistent view of eachpartitioned cache service 1320. For example, the snapshot 1301 canprovide a catalogue of state information of the running system,including metadata 1311 and cache data 1312 for the partitioned cacheservices 1320. Additionally, the system can store the snapshot 1301either in a central location (e.g. a SAN 1321) or in distributed localdisks 1322.

Furthermore, when various artifacts in a snapshot 1301 are created andstored in the distributed local disks 1322, the system can use apluggable (or portable) archiver 1303 to retrieve the persisted stateinformation of the snapshot 1301 from the distributed local disks 1322,and can create a single archive unit 1330, which can be used forauditing or other purposes.

Thus, the system allows a user to take a snapshot on the state of apartitioned cache service in a distributed data grid 1300, instead ofpersisting the cache content in the distributed data grid 1300 in acontinuing fashion.

FIG. 14 illustrates an exemplary flow chart for providing a persistentsnapshot of a running system in a distributed data grid in accordancewith an embodiment of the invention. As shown in FIG. 14, at step 1401,the system allows one or more cache services to run on a plurality ofcluster members in the distributed data grid. Then, at step 1402, thesystem can collect a catalogue of state information associated with saidone or more cache services from the plurality of cluster members in thedistributed data grid. Furthermore, at step 1403, the system can createa snapshot for said one or more cache services running on thedistributed data grid.

The present invention may be conveniently implemented using one or moreconventional general purpose or specialized digital computer, computingdevice, machine, or microprocessor, including one or more processors,memory and/or computer readable storage media programmed according tothe teachings of the present disclosure. Appropriate software coding canreadily be prepared by skilled programmers based on the teachings of thepresent disclosure, as will be apparent to those skilled in the softwareart.

In some embodiments, the present invention includes a computer programproduct which is a storage medium or computer readable medium (media)having instructions stored thereon/in which can be used to program acomputer to perform any of the processes of the present invention. Thestorage medium can include, but is not limited to, any type of diskincluding floppy disks, optical discs, DVD, CD-ROMs, microdrive, andmagneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flashmemory devices, magnetic or optical cards, nanosystems (includingmolecular memory ICs), or any type of media or device suitable forstoring instructions and/or data.

The foregoing description of the present invention has been provided forthe purposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise forms disclosed.Many modifications and variations will be apparent to the practitionerskilled in the art. The modification and variation include any relevantcombination of the described features. The embodiments were chosen anddescribed in order to best explain the principles of the invention andits practical application, thereby enabling others skilled in the art tounderstand the invention for various embodiments and with variousmodifications that are suited to the particular use contemplated. It isintended that the scope of the invention be defined by the followingclaims and their equivalence.

What is claimed is:
 1. A method for supporting persistence in adistributed data grid, comprising: allowing one or more cache servicesto run on a plurality of cluster members in the distributed data grid;collecting a catalogue of state information associated with said one ormore cache services from the plurality of cluster members in thedistributed data grid; and creating a snapshot for said one or morecache services running on the distributed data grid.
 2. The methodaccording to claim 1, further comprising: receiving an on-demand requestfor the snapshot from a user.
 3. The method according to claim 1,further comprising: providing a consistent view for each said cacheservice running on the distributed data grid based on the collectedinformation.
 4. The method according to claim 1, further comprising:allowing the state information to include both meta data and cache datafor said one or more cache services.
 5. The method according to claim 1,further comprising: storing the snapshot in a central location.
 6. Themethod according to claim 1, further comprising: storing the snapshot inone or more distributed local disks.
 7. The method according to claim 6,further comprising: allowing each distributed local disk to be onlyvisible to one or more members in the distributed data grid.
 8. Themethod according to claim 6, further comprising: retrieving persistedstate information in the snapshot from the plurality of cluster membersin the distributed data grid.
 9. The method according to claim 8,further comprising: creating a single archive unit based on theretrieved persisted state information in the snapshot.
 10. The methodaccording to claim 1, further comprising: persisting cache content forsaid one or more cache services in a persistent storage associated withthe distributed data grid.
 11. A system for supporting asynchronousmessage processing in a distributed data grid, comprising: one or moremicroprocessors; a distributed data grid running on the one or moremicroprocessors, wherein the distributed data grid includes a pluralityof server nodes that are interconnected with one or more communicationchannels, and wherein the distributed data grid operates to perform thesteps comprising allowing one or more cache services to run on aplurality of cluster members in the distributed data grid; collecting acatalogue of state information associated with said one or more cacheservices from the plurality of cluster members in the distributed datagrid; and creating a snapshot for said one or more cache servicesrunning on the distributed data grid.
 12. The system according to claim11, wherein: the distributed data grid operates to receive an on-demandrequest for the snapshot from a user.
 13. The system according to claim11, wherein: the snapshot provides a consistent view for each said cacheservice running on the distributed data grid based on the collectedinformation.
 14. The system according to claim 11, wherein: the stateinformation includes both meta data and cache data for said one or morecache services.
 15. The system according to claim 11, wherein: thedistributed data grid operates to store the snapshot in a centrallocation.
 16. The system according to claim 11, wherein: the distributeddata grid operates to store the snapshot in one or more distributedlocal disks.
 17. The system according to claim 16, wherein: eachdistributed local disk is only visible to one or more members in thedistributed data grid.
 18. The system according to claim 15, wherein: anarchiver operates to retrieve persisted state information from theplurality of cluster members in the distributed data grid.
 19. Thesystem according to claim 18, wherein: the archiver operates to create asingle archive unit based on the retrieved persisted state informationin the snapshot.
 20. A non-transitory machine readable storage mediumhaving instructions stored thereon that when executed cause a system toperform the steps comprising: allowing one or more cache services to runon a plurality of cluster members in the distributed data grid;collecting a catalogue of state information associated with said one ormore cache services from the plurality of cluster members in thedistributed data grid; and creating a snapshot for said one or morecache services running on the distributed data grid.